System and method for migrating data from a source file system to a destination file system with use of attribute manipulation

ABSTRACT

A system for migrating data from a source file system to a destination file system while the source file system is in active use, in part by transitioning the client&#39;s use of the source file system to that of the destination file system without unmounting the client from the source file system

TECHNICAL FIELD

Examples described herein relate to a system and method for migratingdata from a source file system to a destination file system with use ofattribute manipulation.

BACKGROUND

Network-based file systems include distributed file systems which usenetwork protocols to regulate access to data. Network File System (NFS)protocol is one example of a protocol for regulating access to datastored with a network-based file system. The specification for the NFSprotocol has had numerous iterations, with recent versions NFS version 3(1995) (See e.g., RFC 1813) and version 4 (2000) (See e.g., RFC 3010).In general terms, the NFS protocol allows a user on a client terminal toaccess files over a network in a manner similar to how local files areaccessed. The NFS protocol uses the Open Network Computing RemoteProcedure Call (ONC RPC) to implement various file access operationsover a network.

Other examples of remote file access protocols for use withnetwork-based file systems include the Server Message Block (SMB), AppleFiling Protocol (AFP), and NetWare Core Protocol (NCP). Generally, suchprotocols support synchronous message-based communications amongstprogrammatic components.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a data migration system that is operable to migratedata from a network file system, according to one or more embodiments.

FIG. 2A through FIG. 2E illustrate sequence diagrams that illustrate thestages of the data migration system 100.

FIG. 3 illustrates a method for implementing a data migration system instages to migrate a source file system without interruption of use toclients that use the source file system, according to an embodiment.

FIG. 4 illustrates a method for actively discovering and asynchronouslyreplicating file system objects of a source file system while the sourcefile system is in use, according to an embodiment.

FIG. 5 illustrates a method for passively discovering and asynchronouslyreplicating file system objects of a source file system while the sourcefile system is in use, according to an embodiment.

FIG. 6 illustrates a method for conducting a pause and restart in thedata migration, according to an embodiment.

FIG. 7 illustrates a method for migrating data from a source file systemto a destination file system while manipulating select attributes inorder to maintain continuity of use by clients of the source filesystem, according to one or more embodiments.

FIG. 8 is a block diagram that illustrates a computer system upon whichembodiments described herein may be implemented.

DETAILED DESCRIPTION

Examples described herein provide a system for migrating data from asource file system to a destination file system while the source filesystem is in active use, in part by transitioning the client's use ofthe source file system to that of the destination file system withoutunmounting the client from the source file system. In order to maintainthe continuity of service to the clients during the data migration, someembodiments provide for intercepting communications between clients andsource/destination file systems, and further provide for manipulatingattributes of responses from the destination file system beforeforwarding those responses to the corresponding clients.

According to some embodiments, requests made from individual clients areforwarded from the source file system to the destination file system,and responses are received from the destination file system for therequesting clients. In one or more of the responses, one or moreattributes of a file system object provided at the destination filesystem and specified in the response are manipulated to match anattribute for a corresponding file system object in the source filesystem. Each of the responses is forwarded to a requesting one of theplurality of clients. The forwarded responses include those responses inwhich the one or more attributes are manipulated.

In another example, a data migration system is provided that includes aserver, positioned in-line as between a plurality of clients and asource file system that is being migrated to a destination file system.In some variations, the data migration system can also be positionedbetween the plurality of clients and the destination file system. In afirst duration in which clients in the plurality of clients request useof the source file system, individual file system objects that are partof the source file system are replicated with the destination filesystem, and requests from individual clients are received and forwardedto the source file system. The destination file system is signaled toperform a set of file system operations that are specified in therequests from the individual clients and which affect the source filesystem. Additionally, the server receives and forward responses from thesource file system to the individual clients who made the requests thatspecified the set of file system operations. In a second duration inwhich the plurality of clients request use of the source file system,requests are forward from individual clients to the destination filesystem, and responses are received from the destination file system. Forone or more of the responses, one or more attributes of a file systemobject provided at the destination file system and specified in theresponse are manipulated to match an attribute for a corresponding filesystem object in the source file system. Each of the responses areforwarded to the requesting clients.

Still further, some described herein include a system for migrating datafrom a source file system to a destination file system, in a manner thatis transparent and seamless to clients of the source file system.

In an embodiment, a data migration system includes a server positionedin-line as between a plurality of clients and the source file system.The server transparently inserts in-line to receive and forwardcommunications as between the source file system and individual clientsof the source file system. While clients in the plurality of clientsrequest use of the source file system, the server implements processesto replicate each file system object that is part of the source filesystem with the destination file system. In response to a client requestthat alters the source file system, the server can operate to (i)forward a response from the source file system to the requesting client,and (ii) queue a file system operation specified by the correspondingrequest, for performance at the destination file system after theresponse from the source file system has been forwarded to the one ofthe plurality of clients.

In another embodiment, file system objects that comprise a source filesystem can be replicated on a destination file system while the sourcefile system handles file system operations from a plurality of clientsthat are mounted to the source file system. When the source file systemand the destination file system are deemed to not be equivalent, aserver asynchronously implements, on the destination file system, thosefile system operations that affect the source file system. Once thesource file system and the destination file system are programmaticallydeemed equivalent, file system operations that affect the source filesystem are implemented synchronously on the destination file system.Each of the plurality of clients can then transition from utilizing thesource file system to using the destination file system.

Still further, in some embodiments, a data migration system thatoperates to migrate data from a source file system to a destination filesystem. Among the operations performed, the data migration systemidentifies a collection of file system objects that are associated witha source file system in active use by a plurality of clients. Individualfile system operations that are intended to be handled by the sourcefile system are intercepted at a location that is in-line and externalto the source file system. The data migration system replicates eachfile system object of the collection at a destination file system. Whenindividual file system operations are determined to after the sourcefile system, the data migration system asynchronously implements the oneor more of the individual file system operations on the destination filesystem.

Still further, in some embodiments, a data migration system canimplement a series of file system operations in order to traverse asource file system and identify file system objects that comprise thesource file system. A data structure is maintained in which eachidentified file system object is associated with an entry and a currentset of attributes for that file system object. Each identified filesystem object is created and maintained on a destination file system.Individual file system operations that are generated from clients forthe source file system are intercepted at a node that is in-line andexternal to the source file system. A corresponding file system objectspecified by each of the file system operations is identified. Adetermination is made from the data structure as to whether thecorresponding file system object has previously been identified. If thecorresponding file system object has not previously been identified,then (i) determining a set of attributes for the corresponding filesystem object, (ii) adding an entry for the corresponding file systemobject and its set of attributes on the data structure, and (iii)replicating the corresponding data object at the destination filesystem.

As used herein, the terms “programmatic”, “programmatically” orvariations thereof mean through execution of code, programming or otherlogic. A programmatic action may be performed with software, firmware orhardware, and generally without user-intervention, albeit notnecessarily automatically, as the action may be manually triggered.

One or more embodiments described herein may be implemented usingprogrammatic elements, often referred to as modules or components,although other names may be used. Such programmatic elements may includea program, a subroutine, a portion of a program, or a software componentor a hardware component capable of performing one or more stated tasksor functions. As used herein, a module or component can exist in ahardware component independently of other modules/components or amodule/component can be a shared element or process of othermodules/components, programs or machines. A module or component mayreside on one machine, such as on a client or on a server, or mayalternatively be distributed among multiple machines, such as onmultiple clients or server machines. Any system described may beimplemented in whole or in part on a server, or as part of a networkservice. Alternatively, a system such as described herein may beimplemented on a local computer or terminal, in whole or in part. Ineither case, implementation of a system may use memory, processors andnetwork resources (including data ports and signal lines (optical,electrical etc.)), unless stated otherwise.

Furthermore, one or more embodiments described herein may be implementedthrough the use of instructions that are executable by one or moreprocessors. These instructions may be carried on a non-transitorycomputer-readable medium. Machines shown in figures below provideexamples of processing resources and non-transitory computer-readablemediums on which instructions for implementing one or more embodimentscan be executed and/or carried. For example, a machine shown for one ormore embodiments includes processor(s) and various forms of memory forholding data and instructions. Examples of computer-readable mediumsinclude permanent memory storage devices, such as hard drives onpersonal computers or servers. Other examples of computer storagemediums include portable storage units, such as CD or DVD units, flashmemory (such as carried on many cell phones and tablets) and magneticmemory. Computers, terminals, and network-enabled devices (e.g. portabledevices such as cell phones) are all examples of machines and devicesthat use processors, memory, and instructions stored oncomputer-readable mediums.

System Overview

FIG. 1 illustrates a data migration system that is operable to migratedata from a network file system, without interrupting the ability ofclient terminals (“clients”) to use the network file system, accordingto one or more embodiments. As shown by an example of a data migrationsystem 100 operates to migrate data from a source file system (“sourcefiler”) 102 to a destination file system (“destination filer”) 104. Eachof the source and destination filers 102, 104 can correspond to anetwork-based file system. A network-based file system such as describedby various examples herein can correspond to a distributed file systemthat is provided in a networked environment, under a protocol such asNFS Version 3 or Version 4. Each of the source and destination filers102, 104 can include logical components (e.g., controller) thatstructure distributed memory resources in accordance with a file systemstructure (e.g., directory-based hierarchy), as well process requestsfor file system objects maintained as part of that file system.

In an example of FIG. 1, data is migrated from the source filer 102while the clients 101 are mounted to and actively using the sourcefiler. More specifically, the data migration system 100 initiates andperforms migration of data from the source filer 102 while clients 101are mounted to the source filer. Among other benefits, the datamigration system 100 can migrate the data from source filer 102 to thedestination filer 104 in a manner that is transparent to the clients,without requiring the clients to first unmount and cease use of thesource filer. By way of example, an administrator of a networkenvironment may seek to migrate data from the source filer 102 to thedestination filer 104 as a system upgrade for an enterprise network,without causing any significant interruption to the services andoperation of the enterprise network.

According to some embodiments, the data migration system 100 isimplemented through use of one or more in-line appliances and/orsoftware. The data migration system 100 can be deployed on a computernetwork in position to intercept client requests 111 directed to sourcefiler 102. The data migration system 100 can include processes thatprovide a data file server 110, as well as cache/memory resources (e.g.,high-speed media) that enable queuing of operations and objects andcaching of file system objects. In an example of FIG. 1, a transparentdata migration system is deployed between the source filer 102 and theclients 101 while the clients actively use the source filer, without anynetwork or reconfiguration of the endpoints. Among other benefits, thedata migration system 100 operates independently, is self-contained, andinstalls in the network path between the clients and file servers.

With further reference to FIG. 1, the data migration system 100 can beimplemented by, for example computer hardware (e.g., network appliance,server etc.) that is positioned in-line with respect to a source filerthat is to be migrated. In particular, the data migration system 100 canbe positioned physically in line to intercept traffic between theclients and the source filer 102. Moreover, the data migration system100 can provide a transparent virtualization of the source filer 102, sothat the client terminals continue to issue requests for use of thesource filer 102 for purpose of intercepting and proxying client/sourcefiler exchanges. In implementation, the data migration system 100 can beoperated to replicate the source filer to the destination filer 104without requiring clients that are utilizing the source filer 102 tohave to remount or otherwise interrupt use of the source filer.

In an embodiment, the transparency in the in-line insertion of the datamigration system 100 is accomplished by configuring the data migrationsystem to intercept and use traffic that is directed to the InternetProtocol (IP) address of the source filer 102. For example, anadministrator of the network environment 10 can configure the datamigration system 100 to utilize the IP addresses of the source filer102, and further to forward traffic directed to the source filer afterthe traffic has been intercepted and processed. Moreover, return trafficdirected from the source filer 102 to the clients 101 can be configured,through manipulation of the filer response, to appear as though thetraffic is being communicated directly from the source filer. In thisway, the data migration system 100 performs various replicationprocesses to migrate the source filer 102 without disrupting theindividual client's use of the source filer 102. As a result, the datamigration system 100 is able to migrate data from the source filer 102,without interruption or performance loss to the clients 101.

In more detail, some embodiments provide for the data migration system100 to include a data file server 110, a file/object lookup component120, a replication engine 124 and a cache engine 132. The data migrationsystem 100 can implement processes that initially populate thedestination filer 104 asynchronously, while the clients actively use thesource filer 102. Moreover, file system operations communicated from theclients 101 can be implemented asynchronously at the destination filer104. The asynchronous nature of the replication and file system updatesfacilitates the ability of the data migration system 100 to eliminate orreduce latency and performance loss in respect to the client's use ofthe source filers. At some point when the source and destination filers102, 104 are deemed equivalent, operations that affect file systemobjects of the source filer 102 can be replayed on the destination filer104 in synchronized fashion. This allows for a subsequent stage, inwhich the destination filer 104 can be used in place of the source filer102, in a manner that is transparent to the clients who have not yetunmounted from the source filer 102.

In an example of FIG. 1, the file system server 110 fields file systemrequests 111 from clients 101 while the replication engine 124implements replication processes that populate and update thedestination filer 104. In one implementation, the file system server 110receives and processes NFS (version 3) packets issued from clients 101.Other file system protocols can also be accommodated. The file systemserver 110 can include logical components that summarize theprotocol-specific request (e.g., NFS request) before processing therequest in a protocol-agnostic manner. The file system server 110 canalso include logic that implement transactional guarantees for each NFSrequest. This logic can determine which NFS (or other protocol) requestsare to be serialized, and which requests can be performed in parallel(e.g., read-type requests). The file system server 110 identifies filesystem objects for replication through either active or passivediscovery. In active discovery, a system process (e.g., “walker 105”)traverses the source filer 102 to determine the file system objects 103.In passive discovery, requests communicated from the clients 101 thatutilize the source filer 102 are inspected in order to identify filesystem objects that need to be migrated or updated on the destinationfiler 104.

As the file system server 110 handles requests from clients 101, sourcecache engine 132 can cache file system objects and metadata of filesystem objects. The source cache engine 132 can implement a variety ofalgorithms to determine which file system objects to cache. For example,the source cache engine 132 can cache file system objects on discovery,and subsequently identify those file system objects that are morefrequently requested. In some implementations, the metadata for the filesystem objects can be cached in a separate cache. Examples of metadatathat can be cached include file handle, file size, c-time (change time)and m-time (modification time) attributes associated with individualfile system objects (e.g., directories, folders, files).

In an example shown by FIG. 1, the source cache engine 132 includes areplay logic 133. The replay logic 133 can be implemented as a componentthat replays operations for creating, modifying or deleting file systemobjects the destination filer 104. As described below, the replay logic133 can be implemented in one or more instances in connection withoperations performed to update or replicate on the source filer 102.

The replication engine 124 operates to implement file system operationsthat replicate file system objects of the source filer 102 and theirexisting states (as provided by the metadata) on the destination filer104. As described below, the replication engine 124 can replicate filesystem objects using file system requests made on the source anddestination filers 102, 104. As such, the replication engine 124 can beimplemented as part of or in addition to the source cache engine 132.Moreover, the operations implemented through the replication engine 124can be performed asynchronously. Accordingly, the replication engine 124can utilize or integrate replay logic 133.

The client requests 111 to the file system server 110 may request filesystem objects using a corresponding file system handle. In someembodiments, the identification of each file system object 113 in clientrequests 111 can be subjected to an additional identification process.More specifically, client requests 111 can identify file system objects113 by file handles. However, the source filer 102 may export multiplevolumes when the clients 101 are mounted, and some clients 101 mayoperate off of different export volumes. In such instances, a filesystem object can be identified by different file handles depending onthe export volume, and different clients may have mounted to the sourcefiler using different export volumes, so that multiple file handles canidentify the same file system object. In order to resolve thisambiguity, data management system 100 utilizes an additional layer ofidentification in order to identify file system objects. In someembodiments, file system objects are correlated to object identifiers(OID) that are based in part on attributes of the requested object. AnOID store 122 record OID nodes 131 for file handles (as describedbelow), and further maintain tables which map file handles to OID nodes131.

In an example of FIG. 1, the file/object lookup 120 uses the OID store122 to map the file handle 129 of a requested file system object to anobject identifier (OID) node 131. Each OID node 131 can include an OIDkey 137 for a corresponding file system object, as well as stateinformation 139 for that file system object. The state information 139can correspond to metadata that is recorded in the OID store 122 for theparticular object.

In one implementation, the OID key 137 for each file system object canbe based on attributes for the file system object. For example, the OIDkey 137 can be determined from a concatenation of an identifier providedwith the source filer 102, a volume identifier provided with the sourcefiler, and other attributes of the object (e.g., a node number asdetermined from an attribute of the file system object). Accordingly,the properties that comprise the OID key 137 can be based at least inpart on the file system object's attributes. Thus, if the file systemserver 110 has not previously identified a particular file systemobject, it will implement operations to acquire the necessary attributesin order to determine the OID key 137 for that file system object.

Once an OID node 131 is created, the file/object lookup 120 adds the OIDnode to the OID store 122. The OID store 122 can correspond to a tableor other data structure that links the file handles of objects for givenexports (or volumes) of the source filer 102 to OID keys 137, so thateach OID key identifies a corresponding file system object.

File System Object Discovery

In one implementation, a system client (“walker 105”) or process can beused to traverse the source filer 102 independently of other requestsmade by clients 101 in order to actively discover objects of the sourcefiler 102. The walker 105 can issue file system operations that resultin a traversal of the source filer 102, including operations thatlaterally and vertically traverse a hierarchy of file system objectsmaintained with the source filer 102.

In addition to fielding requests from the walker 105, file system server110 can also process request 111 from the various clients that activelyuse the source filer 102. When a request is received that specifies afile system object 113, file system server 110 uses the file handle 129of the requested file system object to check whether an objectidentifier (OID) exists for the specified file handle. The request for agiven file system object 113 can originate from any of the clients 101that utilize the source filer 102, including the walker 105. In oneembodiment, the file system server 110 communicates the file handle 129to the file/object lookup 120. The file/object lookup 120 references thefile handle 129 to determine if a corresponding OID node 131 exists. Ifan OID node 131 exists for the file handle 129, then the assumption ismade that the corresponding file system objects 113 in the source filer102 has previously been processed for data migration to the destinationfiler 104.

If the file/object lookup 120 does not identify an OID node 131 for thefile handle 129, then the attributes of the newly encountered object isacquired. One of the components of the data management system 100, suchas the file system server 110 or replication engine 124, can issue arequest 121 from the source filer 102 to obtain the attributes 123 ofthe newly discovered object. The request may be issued in advance of thefile system server 110 forwarding the request to the source filer 102for a response.

Replication Engine

In an embodiment, the file system server 110 processes individual filesystem requests 111, and determines the file handle 129 for each filesystem object. The OID store 122 can be maintained to store OID nodes131 (for discovered objects) as tuples with corresponding file handles129. When the file/object lookup 120 determines that no OID node 131exists in the OID store 122 for a given file handle 129, then thereplication engine 124 is triggered to replicate the corresponding filesystem object to the destination filer 104. Each node in the OID store122 can further be associated with state information that records thestate of the corresponding file system object relative to the sourcefiler 102. In replicating the file system object, the replication engine124 uses attributes of the replicated file system object so that theorganizational structure of the portion of the source filer 102 wherethe replicated file system object is found is also maintained whenreplicated on the destination filer 104. In this way, the source filer102 can be replicated with its organization structure and file systemobjects on the destination filer.

Additionally, as mentioned, an OID node is determined and added to theOID store 122. The entry into the OID store 122 can specify the OID node131 of the new file system object, as well as state information asdetermined from the attributes of the corresponding file system object.In this way, the OID node 131 for the discovered file system object canbe stored in association with the file handle 129 for the same object.

In one implementation, the replication engine 124 acquires theattributes 123 of the newly discovered file system object by issuing afile system attribute request 121 to the source filer 102. For example,in the NFS version 3 environment, the replication engine 124 can issue a“GetAttr” request to the source filer 102. In variations, othercomponents or functionality can obtain the attributes for an unknownfile system object.

Still further, in some variations, the source cache engine 132 canprocure and cache the attributes of the source filer 102. When theattributes are acquired for a given OID node 131 (e.g., replicationengine 124 issues GetAttr request), the request can made to the sourcecache engine 132, rather than to the source filer 102. This offloadssome of the load required from the source filer 102 during the migrationprocess.

The replication engine 124 can implement processes to replicate a filesystem object with the destination filer 104. The processes can recordand preserve the attributes of the file system object, so that theorganization structure of the source filer 102 is also maintained in thereplication process. As mentioned, the replication engine 124 canoperate either asynchronously or synchronously. When operatingasynchronously, replication engine 124 schedules operations (e.g., viareplay logic 133) to create a newly discovered file system object withthe destination filer 104. The asynchronous implementation can avoidlatency and performance loss that might otherwise occur as a result ofthe data migration system 100 populating the destination filer 104 whileprocessing client request for file system objects.

According to some embodiments, the replication engine 124 can replicatethe corresponding file system object by performing a read operation onthe source filer 102 for the newly discovered file system object, thentriggering a create operation to the destination filer 104 (or thedestination caching engine 118) in order to create the discovered filesystem object on the destination filer. Examples recognize, however,that the source filer 102 may inherently operate to process requestsbased on file handles, rather than alternative identifiers such as OIDs.Accordingly, in requesting the read operation from the source filer 102,the replication engine 124 specifies a file handle that locates the samefile system object with the source filer. Furthermore, the file handleused by the issuing client may be export-specific, and each export mayhave a corresponding security policy. For the source filer 102 tocorrectly recognize the read operation from the replication engine 124,the replication engine 124 can be configured to utilize the file handlethat is specific to the client that issued the original request. Byusing the file handle of requesting client, the security model in placefor the client can be mirrored when the read/write operations areperformed by the replication engine 124. In one implementation, the OIDstore 122 may include a reverse lookup that matches the OID key 137 ofthe newly identified file system object to the file handle to which therequest for the file system object was made. In this way, componentssuch as the replication engine 124 can issue requests from the sourceand destination filers 102, 104, using the appropriate file handles.

In one implementation, the replication engine 124 can communicate thefile system object 135 that is to be created at the destination filer tothe replay logic 133. In turn, the replay logic 133 schedules and thenperforms the operation by communicating the operation to the destinationfiler 104. Thus, from the newly discovered file system object 135, thereplay logic 133 can replicate the file system object 155 at thedestination filer 104. The replay logic 133 can, for example, issue acreate operation 139 to replicate the file system object 135 at thedestination filer 104. The replicated file system object 155 can beassociated with the same file handle as the corresponding file systemobject 135 maintained at the source filer 102.

In response to the create operation 139, the destination filer 104returns a response that includes information for determining the OID forthe replicated file system object 155 at the destination. For example,the replication engine 124 can use the response 149 to create adestination OID node 151 for the replicated file system object 155. Thedestination OID node 151 can also be associated with the file handle ofthe corresponding object in the source filer 102, which can bedetermined by the replication engine 124 for the requesting client (andthe requesting client-specific export of the source filer). As such, thedestination OID node 151 of the replicated file system object 155 isdifferent than that of the source OID node 131.

The destination OID store 152 can maintain the destination node OID 151for each newly created file system object of the destination filer 104.The mapper 160 can operate to map the OID node 131 of source file systemobjects to the OID node 151 for the replicated object at the destinationfiler 104. Additionally, when the data migration has matured and thedestination filer 104 is used to respond to clients that are mounted tothe source filer 102, (i) the OID store 122 can map the file handlespecified in the client request to an OID node 131 of the source filer102, and (ii) the mapper 160 can map the OID node 131 of the sourcefiler 102 to the OID node 151 of the destination filer 104. Among otheruses, the mapping enables subsequent events to the file system object ofthe source filer 102 to be carried over and mirrored on the replicatedfile system object of the destination filer 104. Furthermore, based onthe mapping between the OID nodes 131, 151, the determination can bemade as to whether the requested file system object has been replicatedat the destination filer 104.

Additionally, when the migration has progressed to the point that thedestination filer 104 provides the responses to the client requests 111,the mapper 160 can translate the attributes of a file system objectretrieved from the destination filer 104, so that the object appears tohave the attributes of the corresponding object in the source filer 102.By masquerading attributes, the mapper 160 ensures responses from thedestination filer 104 appear to originate from the source filer 102.This allows the clients to seamlessly be transitioned to the destinationfiler 104 without interruption.

In one variation, replication engine 124 triggers creation of thepreviously un-migrated file system object 135 in a cache resource thatis linked to the destination filer 104. With reference to an example ofFIG. 1, replication engine 124 triggers replication of file systemobject 135 to a destination cache engine 118, which carries a copy ofthe file system object in the destination filer 104.

In an embodiment, the replication engine 124 implements certain non-readtype operations in a sequence that is dictated from the time therequests are made. In particular, those operations which are intended toaffect the structure of the source filer 102 are recorded and replayedin order so that the organization structure of the destination filer 104matches that of the source filer 102. In one implementation, the sourcecache 132 (or other component of the data migration system) records thetime when a requested file system operation is received. The replay log133 implements the timing sequence for queued file system operations. Inthis way, the dependencies of file system objects in the source filer102 can be replicated on the destination filer 104. For example,operations specified from the clients 101 to create a directory on thesource filer 102, then a file within the directory can be replicated insequence so that the same directory and file are created on thedestination filer, with the dependency (file within newly createddirectory) maintained.

File System Updates

In addition to replicating newly discovered file system objects, datamanagement system 100 updates file system objects that have beenreplicated on the destination filer 104 with file system operations thatare specified from clients 101 and directed to the source file system102. The file system server 110 may signal the destination filer 104 thefile system operations that after objects of the source filer 102.Examples of such file system operations include those which are of typewrite, create, or delete.

Read type operations, on the other hand, do not affect the objects ofthe source filer 102. When the request 111 from the clients 101 specifyalteration operations (e.g., write, create, delete), the file systemserver 110 (i) determines the OID for the specified file systemobject(s), (ii) communicates the operation 117 with the OID to thesource cache engine 132 (which as described below uses replay logic 133to schedule performance of the operation at the destination filer 104),and (iii) forwards the operation to the source filer 102 (with the filesystem handle). The source filer 102 returns a response 127 to the filesystem server 110. The response 127 is communicated to the requestingclient 101 in real-time, to maintain the transparent performance date ofmigration system 100. Accordingly, when the file system operation 119 isof a read type, it is forwarded to the source filer 102, and thecorresponding response 127 is forwarded to clients 101.

The replay logic 133 operates to intelligently queue file systemoperations that after the source filer for reply at the destinationfiler 104. By way of example, replay logic 133 can implementhierarchical rule-based logic in sequencing when file system operationsare performed relative to other file system operations. For example,file system operations that designate the creation of a directory may beperformed in advance of file system operations which write to thatdirectory. As another example, the replay logic 133 can determine whentwo operations on the same file system object cancel one another out.For example, an operation to create a file system object can be canceledby an operation to delete the same object. If both operations arequeued, the replay logic 133 may detect and eliminate the operations,rather than perform the operations. Still further, during theasynchronous destination population stage, the replay logic 133 candetect when a given operation affects a portion of the source filer 102that has yet to be replicated. In such instances, the replay logic 133can ignore the operation, pending replication of the portion of thesource filer 102 that is affected by the file system operation.

The replay logic 133 can include logic that replays the queued filesystem operations 117 in an appropriate sequence, through thedestination cache engine 118. For example, the destination cache engine118 can maintain file system objects of the destination filer 104. Thereplay logic 133 may implement the operations 117 on the destinationcache engine 118 in order to preserve performance from the destinationfiler 104 as it replicates the source filer 102. As a variation, thereplay logic 133 can directly replay the file system operations at thedestination filer 104. When the data management system operates insynchronous or bypass (see FIG. 2C) mode, the destination cache engine118 further preserve system performance and transparency.

Additionally, the responses 127 to client requests 111 from the sourcefiler 102 can be inspected by the file system server 110 for metadata141, including timing attributes for file system objects. The metadatacan be stored in the OID store 122 as part of each file object's OIDnode. Additionally, when requests are issued on the destination filer104, the responses from the destination filer can be inspected by thereplication engine 124, and attributes detected from the response can bestored with the corresponding destination OID node 151 in thedestination OID store 152.

The mapper 160 can be used to link the OID nodes of the respectivesource and destination OID stores 122, 152, for purposes that includeidentifying destination objects specified in client requests to thesource filer 102. Additionally, the mapper 160 can implement logic tocompare attributes of corresponding OID nodes in order to determinewhether, for example, the replicated object is up to date as comparedthe source object.

Staged Migration

According to embodiments, data migration system 100 implements themigration of the source filer 102 in accordance with stages that affectthe respective states of the source and destinations. FIG. 2A throughFIG. 2E illustrate sequence diagrams that illustrate the stages of thedata migration system 100.

FIG. 2A illustrates an insertion stage for the data migration system203. In the insertion phase, the data management system 203 is insertedin-line and transparently to intercept traffic as between a set ofclients 201 and the source filer 202. The data management system can beconfigured to detect and process traffic bound for the IP address of thesource filer 202. The IP addresses of the source filer 102 can beobtained programmatically or through input from an administrator inorder to intercept incoming traffic without requiring clients tore-mount to the source filer 202.

By way of example, in an NFS environment, clients are programmed toreconnect to a mounted filer when a connection to the filer isterminated. The data migration system 203 can be inserted by terminatinga client's existing connection with the source filer 202, thenintercepting traffic to the source filer once the client attempts tore-set the network connection. The data migration system 203 thenconnects to the clients 201 and uses the IP address of the source filerin order to appear as the source filer. Once connected, the datamigration system 203 acts as a proxy between the client and sourcefiler. Clients 201 can issue requests 204 (e.g., NFS operations) for thesource filer 202, which are intercepted and forwarded onto the sourcefiler by the data migration system. The responses 206 can be receivedfrom the source filer 202 and then communicated to the requestingclients 201.

FIG. 2B illustrates a build stage during which the destination filer 104is populated to include the file system objects of the source filer 102.In the build stage, clients 201 issue requests 211 (read type requests)and 213 (non-read type requests) specifying file system operations fromthe source filer 202. The source filer 202 uses the requests 211, 213(which can include active discovery requests, such as issued from thewalker 105) to determine the file system objects 215 that need to becreated on the destination filer 204. In response to receiving requests211, the data migration system 203 performs an OID check 207 todetermine if the specified file system object 215 has previously beenencountered (and thus migrated).

As noted in FIG. 1, the OID check 207 can be implemented by thefile/object lookup 120 which compares the file handle in the requestwith an OID store 122. If the specified file system object is known,then the file system object is not re-created at the destination filer204. If the specified file system object is not known, then the datamigration system 203 acquires the attributes 216 from the source filer202 (e.g., “Getattr” request 217) and then creates 208 an OID node forthe newly discovered object. With the OID node added, the object isreplicated 214 at the destination filer 204. The replication of theobject is performed asynchronously, using hardware such as cacheresources which can queue and schedule the creation of the file systemobject with the destination filer 204.

While an example of FIG. 2B depicts the attribute request being made ofthe source filer 202, in some implementations, a caching resource (e.g.,source cache engine 132) can cache the attributes of some or all of thefile system objects on the source filer 202. As such, the attributerequest 217 can be implemented as an internal request in which the datamigration system 203 uses its internal cache resources to determine theattributes of a newly discovered file system object.

In addition to replication, file system requests 213 (e.g., write,create, or delete-type requests) which alter the source filer 202 arealso scheduled for replay 219 on corresponding file system objects inthe destination filer 204. The data migration system 203 may implement,for example, replay logic 133 to intelligently schedule and replay filesystem operations at the destination filer 204 that affect the contentsof the source filer 202. Those operations which do not affect thecontents of the source filer (e.g., read type operations 211) areforwarded to the source filer 202 without replay on the destinationfiler 204.

FIG. 2C illustrates a mirroring stage during which the destination fileris synchronously updated to mirror the source file system 202. Themirroring stage may follow the destination build stage (FIG. 2B), afterwhen the source filer 202 and the destination filer 204 are deemedsubstantially equivalent. In one implementation, the mirroring state maybe initiated by, for example, an administrator, upon a programmaticand/or manual determination that the source and destination filers aresubstantially equivalent. In this stage, when the clients 201 issuerequests that alter the source filer 202, the data migration system 203generates a corresponding and equivalent request to the destinationfiler 204. The request to the destination filer 204 can be generated inresponse to the incoming request, without the source filer 202 havingfirst provided a response. Read-type requests 221 can be received by thedata migration system 203 and forwarded to the source filer 202 withoutany mirroring operation on the destination filer 204. The response 231to the read operation 221 are forwarded to clients 201. Other types ofclient-requested operations 223, which can affect the contents of thesource filer 202 (e.g., write, delete, create) are copied 225 andforwarded to the destination filer 204. When the requests 223 arereceived, a copy of the request 225 is generated and communicatedsynchronously to the destination filer 104. The copy request 225 issignaled independently and in advance of the source filer 202 providinga response 233 to the request 223. A response 235 from the destinationfiler 204 can also be received for the copy request 225. As a result,both the source filer 202 and destination filer 204 provide acorresponding response 233, 235.

The data migration system 203 can forward the response 233 from thesource filer 202 to the requesting client 201. However, if the response233, 235 from the source and destination filers are inconsistent,failure safeguards can be implemented. For example, the destination filesystem 204 may be directed to re-replicate the file system object of thesource filer 202. As an alternative or variation, the data managementsystem 203 may revert to asynchronously updating the destination filer204 until the inconsistency between the source and destination filers isdeemed resolved.

FIG. 2D illustrates a cut-over stage, when the destination filer 204 isused to handle client requests while the clients remain mounted to thesource filer 202. As with the mirroring stage, the determination toenter the cut-over stage can be made programmatically and/or manually.In the cut-over stage, the clients 201 still operate to communicate withthe source filer 202. However, the data migration system 203 operates totransparently forward the requests to the destination filer 204 forresponse, and also forwards the response from the destination filer tothe clients 201. Thus, the data migration system 203 forwards allrequests 241 to the destination filer 204, and not to the source filer202. Responses 243 to the requests 241 are forwarded from thedestination filer 204 to the clients 201.

In the cut-over stage, clients 201 operate under the perception thatthey are communicating with the source filer 202. In order to maintainthe operability of the clients, the data management system 203 operatesto provide a programmatic appearance that the source filer 202 is infact providing the response to the client requests. To maintain thisappearance to the clients, the data management system 203 can masqueradethe responses 233, 237 to appear as though the responses originate fromthe source filer 202, rather than the destination filer 204.

In some embodiments, the data migration system 203 implements masqueradeoperations 238 on responses that are being forwarded from thedestination filer 204 to the clients 201. In some implementations suchas provided by NFS environments, the clients 201 require responses 243,247 to include attributes that map to the source filer 202, rather thanthe destination filer 204. Certain metadata, such as time metadata,afters as a result of the replication and/or use of the correspondingobject with the destination filer 204. While the metadata on thedestination filer 204 is updated, in order for the clients 201 toprocess the responses 243, 247, the metadata needs to reflect themetadata as provided on the source filer 202 (which the clientunderstands). The data migration system 203 performs masqueradeoperations 238 which translate the metadata of the responses 243, 247 toreflect the metadata that would be provided for relevant file systemobjects as carried by the source filer 202. By way of example, m-time ofa file system object changes if the data of the corresponding filesystem object changes. The fact that the file system object is returnedfrom the destination filer 204 will mean that the file system objectwill have a different m-time than the source file system 202 if the filesystem object is not modified after it is migrated to the destinationfiler. In order to maintain the attributes of the responses 243, 247consistent for clients 201, the data migration system 203 manipulates aset of attributes in providing the response to the client (e.g.,masquerades the attributes). Specifically, the attributes specified inthe response to the clients are re-written to match the attributes aswould otherwise be provided from the source filer. Thus, for example,the data migration system 200 manipulates, in the response provided backto the client, the attribute received from the destination filercorresponding to the m-time so that it matches the m-time as wouldotherwise be provided from the source filer 202. Other attributes thatcan be manipulated in this manner include, for example, file identifierand file system identifier. With reference to FIG. 1, the file systemserver 110 stores the attributes of file system objects as they arereplicated and updated. For example, the file system server 110 canstore current attributes by inspecting replies from the source filer202, and storing the attributes of file system objects in theirrespective OID node 131.

In addition to manipulating attributes in the response (e.g.,masquerading), data migration system 200 operates to confirm that whennew objects are created on the destination filer 204, the fileidentifiers generated for the object are unique in the namespace of thesource filer 202. In order to accomplish this, one embodiment providesthat the data migration system 200 creates a file object (e.g., dummy)in the source filer 202. The source filer 202 then creates fileidentifier for the new object, and the data migration system 200 is ableto use the identifier as created by the source filer to ensure the newlycreated object of the destination filer 204 is unique in the namespaceof the source filer 202.

FIG. 2E illustrates re-mount state, when the clients re-mount to thedestination filer. According to some embodiments, clients 201 can bere-mount at the destination filer 204 at the convenience of theadministrator. Moreover, the administrator can remount the clients tothe destination filer 204 in rolling fashion (e.g., one at a time) inorder to ensure that any mishaps are isolated. When a client remounts,the destination filer 204 is exported for the client, and the client canuse the destination filer with file handles and metadata that isspecific to the destination filer 204. Exchanges 251, 253 between theclients 201 and the destination are conducted with the destination filerbeing the new source.

Methodology

FIG. 3 illustrates a method for implementing a data migration system instages to migrate a source filer without interruption of use to clientsthat use the source filer, according to an embodiment. FIG. 4illustrates a method for actively discovering and asynchronouslyreplicating file system objects of a source file system while the sourcefile system is in use, according to an embodiment. FIG. 5 illustrates amethod for passively discovering and asynchronously replicating filesystem objects of a source file system while the source file system isin use, according to an embodiment. FIG. 6 illustrates a method forconducting a pause and restart in the data migration, according to anembodiment. FIG. 7 illustrates a method for migrating data from a sourcefile system to a destination file system while manipulating selectattributes in order to maintain continuity of use by clients of thesource file system, according to one or more embodiments. Examples suchas described with FIG. 3 through FIG. 7 can be implemented using, forexample, a system such as described with FIG. 1. Accordingly, referencemay be made to elements of FIG. 1 for purpose of illustrating suitableelements or components for performing a step or sub-step beingdescribed.

With reference to FIG. 3, a data migration system is inserted in-line inthe network path of clients that utilize the source filer (310). Theinsertion of the data migrate system 100 can be transparent, so that theuse of the source filer by the clients is not interrupted. Inparticular, the data migration system replicates data from the sourcefiler into a destination filer without requiring the clients of thesource file or to unmount from the source filer. In one implementation,the data migration system 100 obtains the IP addresses of the sourcefiler. The TCP network connection between the clients and the sourcefiler 102 can be disconnected. When the clients attempt to reconnect tothe source filer, the data migration system intercepts thecommunications to the source filer (e.g., intercepts traffic with the IPaddress of the source filer 102), and then proxies communicationsbetween the clients and the source filer.

Once the data migration system 100 is operational to intercept and proxytraffic between the clients and source filer 102, the data migrationsystem asynchronously populates the destination filer 104 (320). Thiscan include asynchronously replicating objects detected on the sourcefiler 102 at the destination filer 104 (322). In one implementation, thefile system objects of the source filer 102 are queued for replicationat the destination filer 104.

In addition to replication, the source filer 102 can receive clientrequests that specify file system operations that modify the sourcefiler 102 or its contents. In the asynchronous stage, file systemoperations that modify previously replicated objects of the source filer102 are asynchronously replayed at the destination filer 104 (324),where they update the corresponding file system objects.

According to some embodiments, the data migration system can transitionfrom asynchronously updating the destination filer 104 to synchronouslyupdating the destination filer 104 (330). Some embodiments provide for athreshold or trigger for transitioning from asynchronous replication andupdate to synchronous updating of the source filer 102. For example, thetransition from asynchronous to synchronous mode can occur when thesource and destination filer's 102, 104 are deemed to be equivalent,such as at a particular snapshot in time. When synchronously updating,any client request that modifies the source filer 102 is immediatelyreplayed on the destination filer 104. Thus, for example, a replayrequest is issued to the destination filer 104 in response to acorresponding client request for the source filer 102. The replayrequest can be issued to the destination filer independent of theresponse from the source filer 102 to the client request. Thus, the filesystem objects of the source filer 102 and destination filer 104 aresynchronously created or updated in response to the same client request.

At some point when the destination filer 104 is complete (or nearcomplete), the data migration system 100 switches and provides responsesfrom the destination filer 104, rather than the source filer 102 (340).The client can still issue requests to the source filer 102. Read-typeoperations which do not modify file system objects can be responded tofrom the destination filer 104, without forwarding the request to thesource filer 102. Other non-read type operations that modify file systemobjects or the filer can be forwarded to the destination filer 104 forresponse to the client.

According to some embodiments, the data migration system 100 masqueradesresponses from the destination file 104 as originating from the sourcefiler 102 (342). More specifically, the data migration system 100 altersmetadata or other attributes (e.g., timing attributes such as m-time) toreflect metadata of the corresponding file system object residing on thesource filer 102, rather than the destination filer 104. This enablesthe client 101 to seamlessly process the response from the destinationfiler 104.

At a subsequent time, the data migration of the source filer 102 may bedeemed complete. The clients can be unmounted from the source filer 102,and remounted to the destination filer 104 (350). The unmounting andremounting of the clients can occur in a rolling fashion, such as one ata time. This allows an administrator to reconfigure the clients to usethe destination filer 104 with minimal disruption.

With reference to FIG. 4, asynchronous replication of the source filer102 can include active identification of file system objects, which arethen replicated on the destination file 104 (410). In one example, thesource filer 102 is traversed to identify non-migrated file systemobjects (412). A traversal algorithm can be deployed, for example, toscan the file system objects of the source filer 102. The traversalalgorithm can be implemented by, for example, a client-type process(e.g., client process provided on server) that issues requests to thesource filer 102 for purpose of scanning the source filer. Theattributes for individual file system objects can used to determinewhether the particular file system object had previously been migratedto the destination filer 104. If the data migration system 100 has notacquired the attributes for a file system object, then the object may bedeemed as being non-migrated or newly discovered. Once identified, theattribute for each such file system object is retrieved (414).

From the attribute, the identifier for the file system object isdetermined and recorded (420). The identifier can uniquely identify thefile system object. A record of the file system object and itsattributes can be made and stored in, for example, a correspondinglookup store. Additionally, the attributes of the file system object canbe used to determine a state of the particular file system object.

The identified file system object can then be queued for replication atthe destination file system 104 (430). For example, the replicationengine 124 can schedule replication of the file system object at thedestination filer 104.

With reference to FIG. 5, asynchronous replication of the source filer102 can also include passive identification of file system objects,where file system objects are identified for replication from clientcommunications that send requests (e.g., NFS type requests) to thesource filer 102. In implementation, the data migration system receivesclient request for file system objects that reside on the source filer102 (510). A determination is made as to whether the file system objecthas previously been migrated to the destination filer (512). Asdescribed with an example of FIG. 1, the determination may be based onthe identifier of the file system object, which can be based in part onthe attributes of the object. For example, an OID key can be determinedfor the file system object and then used to determine whether the objectwas previously migrated to the destination filer 104.

If the determination is that the object has previously been migrated,the client request is forwarded to the source filer 102 for a response(530). If, however, the determination is that the object has notprevious been migrated, a sequence of operations may be queued andasynchronously implemented in which the file system object is replicatedon the destination file system 104 (520). The asynchronous replicationof the file system object enables the client requests to readily beforwarded to the source filer for response (530). If the forwardedrequest is a read-type request (532), a response is received from thesource filer for the read request and forwarded to the client (542). Ifthe forwarded request is a non-read type request that modifies arealters the source filer or its objects (534), then (i) the response isreceived from the source filer 102 and forwarded to the client (542),and (ii) the request from the client is queued for replay on acorresponding replicated file system object of the destination filer 104(544).

In FIG. 6, data migration system 100 can be initiated to migrate datafrom the source filer to the destination filer. As mentioned withvarious embodiments, file system objects of the source filer 102 can bedetected (e.g., actively or passively), and attributes for the detectedfile system objects are recorded (610). Additionally, the attributes offile system objects can be recorded from responses provided by thesource filer to client requests (620).

While the data migration system is taking place, the data migrationsystem 100 and can be paused for a period of time, then restarted (622).For example, an administrator may pause the data migration system 100prior to the completion of the asynchronous build stage. When paused,the source filer 102 remains in active use, and clients can modify thecontents of the source filer by adding, deleting or modifying filesystem objects of the source filer. When the data migration systemreturns online, the data migration system does not know what changestook place while it was paused. Rather to initiate the whole processover, again, the data migration system 100 can reinitiate active and/orpassive file system object detection.

When a file system object of the source filer's detected (630), theattributes of the file system object can be checked to determine whetherthat particular file system object represents a modification to thesource filer that occurred during the pause (632). Specific attributesthat can be checked include timing parameters, such as modification time(m-time). The OID node 131 (see FIG. 1) for a given file system objectcan also include its attributes as recorded at a given time. In theresponse to the client request (whether active or passive), theattributes of the file system object can be inspected and comparedagainst the recorded values. A determination can be made as to whetherthe values of the file system object indicate that the file systemobject had been updated during the pause (635). If the determinationindicates that the file system object was updated, then the particularfile system object is replicated again on the destination filer 104(640). For example, the file system object can be queued by thereplication engine 124 for replication at a scheduled time. If thedetermination indicates that the file system object was not updated,then no further re-replication is performed (642).

With reference to FIG. 7, a data migration process is performed tomigrate file system objects from the source filer 102 to the destinationfiler 104. For example, with reference to FIG. 2A through FIG. 2C, datamigration system 100 can be inserted in-line with respect to clients andthe source and destination filers 102, 104. An asynchronous replicationprocess can be initiated while the clients 101 actively use the sourcefiler 102. Furthermore, operations that affect the source filer 102(e.g., write operations) are mirrored on the destination filer. As shownby FIG. 2C, once the source filer 102 and the destination filer 104 aresubstantially equal, a mirroring state may occur in which file systemoperations specified in the client requests 111 for the source filer 102are mirrored on the destination filer 104.

As shown by FIG. 2D, a cut-over stage can follow in which authority forresponding to client requests 111 is transferred from the source filer102 to the destination filer 104 (710).

Once authority is transferred, the data migration system 100 forwardsclient requests 111 to the destination filer 104 (720). This is incontrast to preceding stages in which the source filer 102 is used toprovide the response to the client requests.

Responses from the destination filer 104 are received and forwarded tothe clients 101 (730). While responses are generated from thedestination filer 104, examples recognize that the clients 101 operatein a manner that has them connected to the source filer 102, rather thanthe destination filer 104. Examples recognize that the clients 101 useof the source/destination filers can be disrupted if the attributesprovided in the responses to the client requests include certainattributes which omit values carried on the source filer 102, but rathercarry values from the destination filer 104. In such cases, the datamigration system 100 operates to change the attributes in the responsesof the destination filer 104, before forwarding those responses to therespective clients.

In more detail, examples described herein recognize that the file systemobjects specified in some responses to client requests 111 require oneor more attributes to be manipulated (740). Among the attributes, theresponse from the destination filer 104 may need to include identifiers,such as the file handle or filer identifier, that originate from thesource filer 102. Accordingly, attributes included in the response fromthe destination filer 104 can be mapped (e.g., using mapper 160) tocorresponding attributes provided by the source filer 102 (742). Forexample, the destination OID 152, mapper 160 and OID store 122 can beused to map attributes provided in the response from the destinationfiler 104 to the attribute that would have otherwise been provided hadthe response originated from the source filer 102.

In some embodiments, time attributes of some file system objectsspecified in some responses the destination filer 104 can also bemanipulated to reflect the time attribute of a corresponding file systemobject provided by the source filer 102 (744). In one embodiment, adetermination can be made for a given response as to whether a specifiedfile system object should include an attribute of modification time (orM-time) as reflected for a corresponding file system object of thesource filer (745). The M-time for a given file system object can beupdated by a corresponding filer each time the file system object ismodified. Accordingly, the determination can be based in part on whetherthe specified file system object was modified after the transfer inauthority took place (e.g., as shown in FIG. 2D). If the file systemobject specified in the response from the destination filer 104 has notbeen modified since after the transfer, then the M-time of the sourcefiler 102 is used in the response (746). For example, the mapper 160 canuse the M-time value provided in the OID store 122 to modify theattribute in the response provided from the destination filer 104, sothat it includes the M-time as would have been provided from the sourcefiler 102. Once the change has been made, the file system server 110 canforward the response back to the client 101. Alternatively, aprogrammatic component of the data migration system 100 (e.g., mapper160) can retrieve a metadata set from the source filer 102 for thecorresponding file system object.

Conversely, if the file system object specified in the response from thedestination filer 104 has been modified since the transfer to thedestination filer, then the M-time of the destination filer 104 is usedin the response (748).

Other examples of attributes that can be modified by the file systemserver 110 include attributes which identify a user or user class. Forexample, the source filer 102 may have provided an export for theclients 101 that identify a set of users, and a different set of usersmay be defined on the destination filer 104. In such cases, the filesystem server 110 can again map an attribute of a user, as provided inthe response from the destination filer 104, to one that is recognizedor in use by the source filer 102.

Similarly, attributes that affect security policies can be mapped ininstances when the security policies of the destination filer 104 do notmatch that of the source filer 102. For example, if the destinationfiler provides a response that includes attributes for a first securitypolicy, the file system server 110 can determine whether the attributewould be in compliance with the security policy of the source filer 102.If there is no match, the source filer 102 can manipulate the attributeof concern so as to maintain the appearance of compliance with thesecurity policy of the source filer 102.

Still further, some examples provide that the file system server 110performs a fake object creation on the source filer 102 in cases such aswhen the client 101 requests the creation of a new file system objectwhen authority has been transferred to the destination filer 104 (seeFIG. 2D). In such cases, the file system object and the metadata may bereplicated on the source filer 102 in order to maintain consistencybetween the source and destination filer 102, 104.

Computer System

FIG. 8 is a block diagram that illustrates a computer system upon whichembodiments described herein may be implemented. For example, in thecontext of FIG. 1 and FIG. 2A through 2E, data migration system 100 (or203) may be implemented using one or more computer systems such asdescribed by FIG. 7. Still further, methods such as described with FIG.3, FIG. 4, FIG. 5, FIG. 6 and FIG. 7 can be implemented using a computersuch as described with an example of FIG. 8.

In an embodiment, computer system 800 includes processor 804, memory 806(including non-transitory memory), storage device 810, and communicationinterface 818. Computer system 800 includes at least one processor 804for processing information. Computer system 800 also includes a mainmemory 806, such as a random access memory (RAM) or other dynamicstorage device, for storing information and instructions to be executedby processor 804. Main memory 806 also may be used for storing temporaryvariables or other intermediate information during execution ofinstructions to be executed by processor 804. Computer system 800 mayalso include a read only memory (ROM) or other static storage device forstoring static information and instructions for processor 804. A storagedevice 810, such as a magnetic disk or optical disk, is provided forstoring information and instructions. The communication interface 818may enable the computer system 800 to communicate with one or morenetworks through use of the network link 820 (wireless or wireline).

In one implementation, memory 806 may store instructions forimplementing functionality such as described with an example of FIG. 1,FIG. 2A through FIG. 2E, or implemented through an example method suchas described with FIG. 3 through FIG. 7. Likewise, the processor 704 mayexecute the instructions in providing functionality as described withFIG. 1, FIG. 2A through FIG. 2E, or performing operations as describedwith an example method of FIG. 3, FIG. 4, FIG. 5, FIG. 6 or FIG. 7.

Embodiments described herein are related to the use of computer system800 for implementing the techniques described herein. According to oneembodiment, those techniques are performed by computer system 800 inresponse to processor 804 executing one or more sequences of one or moreinstructions contained in main memory 806. Such instructions may be readinto main memory 806 from another machine-readable medium, such asstorage device 810. Execution of the sequences of instructions containedin main memory 806 causes processor 804 to perform the process stepsdescribed herein. In alternative embodiments, hard-wired circuitry maybe used in place of or in combination with software instructions toimplement embodiments described herein. Thus, embodiments described arenot limited to any specific combination of hardware circuitry andsoftware.

Although illustrative embodiments have been described in detail hereinwith reference to the accompanying drawings, variations to specificembodiments and details are encompassed by this disclosure. It isintended that the scope of embodiments described herein be defined byclaims and their equivalents. Furthermore, it is contemplated that aparticular feature described, either individually or as part of anembodiment, can be combined with other individually described features,or parts of other embodiments. Thus, absence of describing combinationsshould not preclude the inventor(s) from claiming rights to suchcombinations.

What is claimed is:
 1. A data migration system comprising: a server positioned in-line as between a plurality of clients and a source file system, and between the plurality of clients and a destination file system, the server performing operations that include: during a first duration in which the plurality of clients request use of the source file system: replicate individual file system objects that are part of the source file system with the destination file system, forward requests from individual clients in the plurality of clients to the source file system, signal the destination file system to perform a set of file system operations that are specified in the requests from the individual clients in the plurality of clients and which affect the source file system, and receive and forward responses from the source file system to the individual clients who made the requests that specified the set of file system operations; during a second duration in which clients in the plurality of clients request use of the source file system: forward requests from individual clients in the plurality of clients to the destination file system, receive responses from the destination file system to the forwarded requests, for one or more of the responses, manipulate one or more attributes of a file system object provided at the destination file system when it is specified in the response to match an attribute for a corresponding file system object in the source file system, and forward each of the responses to one of the plurality of clients that made a corresponding request, the forwarded responses including the one or more responses in which one or more attributes of the specified file system object of the destination file system are manipulated.
 2. The system of claim 1, wherein the one or more attributes correspond to one or more attributes selected from a group consisting of a time stamp, file identifier, file system identifier and user identifier.
 3. The system of claim 1, wherein the one or more processors manipulate the one or more attributes by manipulating a time stamp of when the file system object was modified.
 4. The system of claim 3, wherein the one or more processors manipulate the time stamp to reflect a time stamp of the file system object provided at the source file system only if the file system object was last modified during the first duration.
 5. The system of claim 1, wherein the one or more processors manipulate the one or more attributes when it is specified in the response by manipulating a change time of when the file system object was created.
 6. The system of claim 1, wherein the one or more processors manipulate the one or more attributes by mapping a user attribute of the destination file system to one of the source file system.
 7. The system of claim 1, wherein the one or more processors determine when a given client request specifies a creation of a new file system object, and wherein the one or more processors communicate an operation to each of the source file system and the destination file system to create the file system object on each of the source and destination file systems.
 8. The system of claim 1, wherein the server receives and forwards client requests and responses using a Network File System protocol.
 9. A method for migrating data from a source file system to a destination file system, the method being implemented by one or more processors and comprising: (a) forwarding requests for the source file system, from individual clients in the plurality of clients, to the destination file system; (b) receiving responses from the destination file system to the requests from the individual clients in the plurality of clients; (c) for one or more of the responses, manipulating one or more attributes of a file system object provided at the destination file system as specified in the response, so that the one or more attributes each match an attribute for a corresponding file system object in the source file system; and (d) forwarding each of the responses to a requesting one of the plurality of clients, including the one or more responses that include the manipulated one or more attributes.
 10. The system of claim 9, wherein the one or more attributes correspond to one or more attributes selected from a group consisting of a time stamp, file identifier, file system identifier and user identifier.
 11. The method of claim 9, wherein (a) through (d) are performed in a second duration that follows a first duration, wherein the method further comprising performing operations during the duration that comprise: receiving requests from the plurality of clients to use of the source file system; replicating individual file system objects that are part of the source file system with the destination file system; forwarding requests from individual clients in the plurality of clients to the source file system; and signaling the destination file system to perform a set of file system operations that are specified in the requests from the individual clients in the plurality of clients and which affect the source file system; receiving and forwarding responses from the source file system to the individual clients who requested use of the source file system.
 12. The method of claim 9, wherein the method is performed at a node that is positioned in-line as between the plurality of clients and the destination file system.
 13. The method of claim 9, wherein manipulating the one or more attributes includes manipulating a time stamp of when the file system object was modified when the time stamp is specified in the response.
 14. The method of claim 13, wherein manipulating the time stamp includes providing the time stamp from the source file system in the response only when the file system object was last modified during the first duration.
 15. The method of claim 9, wherein manipulating the one or more attributes includes manipulating a change time of when the file system object was created when specifying the change time in the response.
 16. The method of claim 9, wherein manipulating the one or more attributes includes mapping a user attribute of the destination file method to one of the source file system.
 17. The method of claim 9, further comprising determining when a given client request specifies a creation of a new file system object, and communicating a first operation to the destination file system to create a new object for the file system object on the destination file system, and communicating a second operation to the source file system to create a second file system object on the source filer, then determining one or more identifiers for the new object on the destination filer using an identifier of the second file system object.
 18. The method of claim 9, wherein the method is performed using a Network File Method protocol.
 19. A computer-readable medium that stores instructions for migrating data from a source file system to a destination file system, the instructions being executable by one or more processors to perform operations that comprise: (a) forwarding requests for the source file system, from individual clients in the plurality of clients, to the destination file system; (b) receiving responses from the destination file system to the requests from the individual clients in the plurality of clients; (c) for one or more of the responses, manipulating one or more attributes of a file system object provided at the destination file system as specified in the response, so that the one or more attributes each match an attribute for a corresponding file system object in the source file system; and (d) forwarding each of the responses to a requesting one of the plurality of clients, including the one or more responses that include the manipulated one or more attributes.
 20. The computer-readable medium of claim 19, wherein instructions for performing (a) through (d) are performed in a second duration that follows a first duration during which operations are performed that include: receiving requests from the plurality of clients to use of the source file system; replicating individual file system objects that are part of the source file system with the destination file system; forwarding requests from individual clients in the plurality of clients to the source file system; and signaling the destination file system to perform a set of file system operations that are specified in the requests from the individual clients in the plurality of clients and which affect the source file system; receiving and forwarding responses from the source file system to the individual clients who requested use of the source file system.
 21. The computer-readable medium of claim 20, wherein the one or more attributes correspond to one or more attributes selected from a group consisting of a time stamp, file identifier, file system identifier and user identifier.
 22. The computer-readable medium of claim 19, wherein the operation is performed at a node that is positioned in-line as between the plurality of clients and the destination file system.
 23. The computer-readable medium of claim 19, wherein instructions for manipulating the time stamp includes instructions for providing the time stamp from the source file system only when the file system object was last modified during the first duration. 